Ivanti appelle ses clients à patcher EPMM et à vérifier leurs comptes administrateur après la découverte d’une faille déjà exploitée à petite échelle. En cause, un scénario d’attaque qui nécessite déjà des droits élevés, mais peut tourner au vrai problème si des identifiants privilégiés ont fuité.
Nouvelle alerte chez Ivanti, et toujours sur un produit sensible. L’éditeur vient de publier des correctifs pour Endpoint Manager Mobile, sa solution de gestion de terminaux mobiles en version on-premise, après la découverte d’une faille permettant d’exécuter du code à distance sur les systèmes vulnérables. La brèche, suivie sous la référence CVE-2026-6973 (CVSS 7.2), nécessite des privilèges admin et aurait déjà été exploitée dans un nombre très limité de cas.
Des données mal filtrées permettant l’exécution de code arbitraire
Dans le détail, la vulnérabilité concerne les versions 12.8.0.0 et antérieures d’EPMM, la solution d’Ivanti qui sert à administrer des flottes mobiles, avec tout ce que cela suppose d’accès sensibles, de terminaux enrôlés et de politiques de sécurité centralisées.
Elle repose sur un défaut de validation des entrées, c’est-à-dire un contrôle insuffisant des données reçues par le serveur avant leur traitement. Pour en tirer parti, un attaquant doit déjà disposer de droits administrateur avant de pouvoir exécuter du code arbitraire sur le système ciblé. Le risque concerne donc essentiellement les environnements déjà fragilisés par une fuite d’identifiants, une réutilisation de mot de passe sur un autre service, voire une compromission antérieure d’un compte admin.
Même avec cette condition préalable, Ivanti confirme avoir observé un nombre limité d’attaques au moment de la divulgation de la faille, sans donner davantage de détails sur les cibles ni sur la méthode employée. L’éditeur précise que le problème touche uniquement EPMM dans sa version installée chez les clients. Ivanti Neurons for MDM, son offre cloud, Ivanti EPM, Ivanti Sentry et les autres produits de l’entreprise ne seraient pas concernés.
Des instances toujours exposées et des comptes à vérifier
D’après Shadowserver, plus de 780 adresses IP associées à des empreintes Ivanti EPMM étaient encore visibles en ligne au 9 mai, majoritairement en Europe (474) et en Amérique du Nord (176). Le relevé ne permet pas de savoir combien d’instances ont déjà été corrigées, ni combien correspondent encore à des serveurs vulnérables, mais il donne une idée du nombre d’installations exposées sur Internet.
Pour les organisations concernées, la priorité consiste à installer les versions corrigées publiées par Ivanti, soit EPMM 12.6.1.1, 12.7.0.1 ou 12.8.0.1 selon la branche utilisée. L’éditeur recommande aussi de passer en revue les comptes administrateur et de renouveler les identifiants si besoin. Les clients ayant appliqué les mesures préconisées en janvier, après l’exploitation de CVE-2026-1281 et CVE-2026-1340, seraient déjà moins exposés à cette nouvelle faille.
Une RCE (Remote Code Execution) permet à un attaquant de faire exécuter des commandes ou du code sur un serveur à distance, comme s’il y avait accès localement. Dans un outil MDM/EPMM, c’est particulièrement sensible car le serveur pilote l’enrôlement des terminaux, les politiques de sécurité et parfois la distribution d’applications ou de certificats. Une RCE peut donc servir de point d’entrée pour déployer des charges malveillantes, altérer des configurations ou rebondir vers d’autres systèmes internes. Le niveau de risque dépend aussi des prérequis d’exploitation (ici, des droits admin sont nécessaires), mais l’impact potentiel reste élevé si ces accès sont déjà compromis.
Que signifie un défaut de validation des entrées (input validation) dans une application serveur, et comment cela peut mener à l’exécution de code arbitraire ?La validation des entrées consiste à contrôler strictement les données reçues (paramètres HTTP, champs de formulaire, API) avant de les traiter. Quand ce contrôle est insuffisant, une donnée malformée peut être interprétée comme une instruction et non comme un simple contenu, selon le composant touché (moteur de templates, interpréteur, commande système, bibliothèque). Cela ouvre la porte à des injections (commande, script, expression) pouvant aller jusqu’à l’exécution de code arbitraire sur le serveur. Dans la pratique, le correctif vise généralement à filtrer/échapper les entrées, imposer des formats attendus et supprimer les chemins d’exécution dangereux.
Pourquoi une faille “exploitée” mais nécessitant des privilèges administrateur reste-t-elle un problème concret, et que recouvre la vérification des comptes admin ?Le fait qu’une exploitation exige déjà des droits admin ne rend pas la faille anodine : il suffit que des identifiants privilégiés aient fuité, aient été réutilisés ailleurs, ou aient été volés lors d’une compromission précédente. Une fois connecté avec ces droits, l’attaquant peut enchaîner (“post-exploitation”) et transformer une vulnérabilité applicative en prise de contrôle du serveur. Vérifier les comptes admin implique typiquement d’auditer la liste des administrateurs, repérer les comptes inattendus, contrôler les journaux de connexion, et désactiver les accès non nécessaires. Le renouvellement des identifiants va souvent avec la rotation des mots de passe, la révocation de jetons/sessions actives et, idéalement, l’activation d’une MFA adaptée aux comptes à privilèges.
